fix(observer): log_for_query_filter drops every log (undefined self, swallowed NameError) - #200

The bug

log_for_query_filter in aiopslab/observer/log_api.py is a module-level function, but its body reads self.log_pod_list:

def log_for_query_filter(logs):            # line 365 -- no `self` parameter
    filtered_log = []
    for log in logs:
        try:
            cmdb_id = log["_source"]["kubernetes"]["pod"]["name"]
            if cmdb_id not in self.log_pod_list:     # line 370 -- `self` is undefined
                continue
        except Exception as e:
            continue                                 # ... and this swallows the NameError
        filtered_log.append(log)
    return filtered_log

self is not a parameter, not a global, and not a closure variable, so evaluating it raises NameError on the very first log. The bare except Exception: continue immediately below catches it and skips that log — and since every log takes exactly the same path, the function returns an empty list regardless of what Elasticsearch returned.

It has one caller, at the end of LogAPI.query():

data = log_for_query_filter(data)   # line 250
print("len data", len(data))        # always prints 0

So LogAPI.query() always yields nothing. Because the exception is swallowed, there is no traceback and no log line — the query just silently comes back empty, which reads as "Elasticsearch had no matching logs" rather than as a bug.

python -m pyflakes on main flags it:

aiopslab/observer/log_api.py:370:31: undefined name 'self'

The fix

Take the pod list as a parameter and pass self.log_pod_list from the one call site — that is the value the function was reaching for, and it is already available in LogAPI.query().

Verification

log_for_query_filter was extracted with ast and run directly (no elasticsearch/kubernetes imports needed) on sample ES hits, two of which are from monitored pods:

input: 3 ES hits, 2 of them from monitored pods
       pods monitored: ['frontend-1', 'cartservice-2']

upstream -> kept 0 hits: []
patched  -> kept 2 hits: ['a', 'c']

The loadgenerator-9 hit is still filtered out, which is the intended behaviour — initialize_pod_and_service_lists() deliberately excludes loadgenerator-* and redis-cart pods.

One related note (not changed here)

log_processing_online_boutique (line 330) has the identical problem — module-level, reads self.log_pod_list at line 339, inside a try/except Exception: continue. I left it alone because its only call site is commented out (line 138), so it is not reachable today. Happy to fold the same change into this PR if you'd like it fixed before that line is ever re-enabled.

🤖 Generated with Claude Code